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(54) A dynamic distributed multicast routing protocol 



(57) The distribution of multicast information in a 
communications network formed from a plurality of com- 
munications nodes, e.g., ATM switches, is enhanced by 



providing an efficient mechanism for routing a request 
to join a mis feast connection \o an orig inator of the mul- 
ticast and an efficient mechanism for then connecting 
the requester'!© the multicast connection. 
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FIELD OF THE INVgfimQN: 

The invention rebates to data networks and more 
particularly folates to a multicast protocol for beating, 
joining and leaving a multicast group that is receiving 
particular information. 

SAO KjBRQUMP OF TH E J N VENTi OM: 

Present!y : a user associated with a multimedia ter- 
minal, eg, a conventional workstation or PC , may enter 
a request via the terminal to participate in a particular 
event, e.g. , a lecture, audio/video conference, televised 
speech, etc., that is being provided by a node, e.g.. a 
packet switch; in a digital network. The event is typically 
associated with some type of identi: ler, le, t group iden- 
tifier (e.g., 800 number or conference bridging number 
I'n.GOiwentiohal telephone networks) so that a user who 
wants to participate in the event may identify the event 
in a request that the user submits ?o his/her terminal 
The user's terminal then forwards the request to an as- 
sociated serving node within the digital network. A group 
identifier may represent a collection of users who are 
interested in particular information associated with the 
event. (Note that group identifier is different from an 
identifier that is used to identify a particular user} Typi- 
cally the membership associated with a group identifier 
may be - dynamic such that a member may join and leave 
the group at any time. Also, there is no restriction on the 
physical location of multicast group members who may 
or may not be at the same physical location. The net- 
work maintains information relating to the group and typ- 
ically does this by constructing a network directory 
which is used to track the connectivity of active merrv 
bars. That is. a serving node submits the group identifier 
to the network directory The directory., in turn, returns 
the address of the nearest node which it can join. The 
serving node then sends a request to join the. multicast 
group to the identified node. Anode that, joins- or leaves 
a multicast group must notify the directory so that it can 
update the membership information. Unfortunately; 
membership may change so frequently that manage- 
ment of such a directory may become costly and ineffi- 
cient. 

The network may also maintain such membership 
by constructing a multicast server in the network. Data 
that Is sent by a user Is then first del ivered to the server. 
which, in turns, delivers the information to ail other mem- 
bers in the multicast group. Although this approach ap- 
pears to be simple to implement it t nevertheless, may 
lead to a single point of failure in the event that the server 
fails. Moreover, this approach does not use the network 
resources efficiently, since user data has to be sent to 
the server. 



The foregoing is addressed and the relevant an is 
advanced by providing an efficient and scaiaabte mech- 

s an.ism for a data network to maintain multicast group in- 
formation in a distributed fashion m which any node in 
the network may automatically locate, join and leave a 
multicast group. The mechanism is distributed so that a 
single node has to maintain complete information about 

to the other participants of the multicast group. In particu- 
lar, in accordance with an illustrative embodiment of the 
invention, a network node enters a request to pin a mul- 
ticast group, by constructing at least one routing tree- 
formed f rom selected paths to each of a number of other 

1$. nodes identified in the tree and sending a find message 
identifying the multicast group to the selected nodes in 
accordance with the routing tree, in response to receipt 
of a message identifying the nearest node connected to 
the multicast group, the requesting node then simply 

2° sends a join message to the identified node to join the 
multicast group. 

These and other aspects of the claimed invention 
are disclosed in the ensuring detailed description, ac- 
companying drawings and claims. 

BBiEF DESCRtPTIQN OF THE DRAW^QS: 

In the drawing: 

so FIG. i shows a communications network in which 
the principles of the invention may be practiced; 

FIG. 2 illustrates a routing tree rooted at a particular 
one of the nodes of FIG t; 

55 

FIG. 3 shows a state diagram illustrating the oper- 
ation of a node in accordance with the principles of 
the invention; 

40 FIGs. 4-9 are respective expanded versions of the 
operations states shown in FIG: 3, and 

FiGs. 1 0-1 5 illustrate the operation of the principles 
of the invention in an illustrative hierarchical net- 
45 work. 

DETAILED DESCRIPTION: 

Our inventive protocol supports what we call a °Par- 
$o iieipant-lntoted Join-, in which a node initiates a re- 
quest to join a multicast group and, in doing so, deter- 
mines the network path that is to be used to join the mul- 
ticast. The protocol has two phases. We call the first 
phase the "Find" phase, since ft is the requesting node 
55 that determines the identity of the nodes that are already 
on the multicast tree. We calf the second phase the 
s Jd!n f! phase, since the requesting node attempts to join 
the nearest noda that is already on the multicast tree, in 



the Find phase, a node that wants to joh the myltjcast 
group originates a REQUEST massage and sends it to 
ail of its neighbors on the shortest path tree rooted at 
the requesting node. A ne i ghbor that fecetves the mes- 
sage then forwards it downstream to its neighbors along 
the links of the shortest path tree rooted at the originat- 
ing: node. This process continues until the REQUEST 
message reaches either a node that is already on the 
multicast tree or a leaf node of the shortest path tree 
rooted Bt the originating node (i.e., the node that has the 
sought-after multicast information.} Each node that isal- 
ready on the multicast tree replies to the request with 
the cost parameter set to 0, The leaf nodes that are not 
on the multicast tree reply to the request with the cost 
parameter set to -1. On receiving aJI of the replies to. the 
message, a node determines the nearest node and for- 
wards the REPLY message from the nearest node up- 
stream towards the originator of the REQUEST Before 
doing so ; the node updates the cost function to reflect 
the cost from this node to the nearest node. The origi- 
nator receives all the replies and determines the nearest 
node. This ends the Find phase, In she Join phase, the 
requesting node determines the path to the nearest 
node and sends a JOi N-REQ message. The determined 
path is inserted in the message so that an intermediate 
node does not have to make the same determination. 
The nearest node (having the sough t-after .information) 
replies with a JOI N-ACK message and ai! the nodes in 
the path become a branch of the multicast tree. 

An illustrative example of the foregoing is shown in 
RG 1 . in which sought-after multicast information is as* 
■sunned to be a multimedia event 150, e.g., a .televised 
lecture. Multimedia signals characterizing the multime- 
dia event are supplied to node 105, which may operate 
as a conventional video server for the purpose of sup- 
plying the video signal in the form of digital signals to a 
user who has entered a request to receive a. copy of 
such signals via network 100 formed from dais nodes 
105, 11.0, 11.5, 120, 125, 130 and 135. In an illustrative 
embodiment of the invent ion , each of the nodes may be, 
for example, a conventional ATM switch. Assume that a 
user associated with workstation 170 in a conventional 
manner enters a request via a keyboard (not shown) to 
view the event on monitor 175, in which the request In- 
cludes an identifier associated with the multimedia 
event. The request, however, does not contain the iden- 
tity {e.g., address) of the source of the multicast infor- 
mation. Workstation 170, in response to receipt of the 
request, converts the request into a form expected by 
associated network node 125, also shown as the E 
node. As an aspect of the invention., network 100 does 
not include a directory identifying the information that is 
respectively supplied by the network 100 nodes. Ac- 
cordingly to locate the node that has the multicast in- 
formation, node 125 will poll each of the other network 
100 nodes. Before doing so, however, node 1 25 con- 
structs a tree formed from selected paths to each of the 
other nodes, in which the selection Is based on prede- 



termined parameter, for example, cost, number of hops, 
etc. In an illustrative embodiment of the invention, cost 
is characterized by a weight value, Such weight values 
are shown in parentheses in FIG. 1 and are used, as 

£ mentioned, to ident if y a least cost paib/ro ute , For exam- 
pie, if node 120 (D) needs to send a message to node 
105 (A), then node 120 wilt likely send the message via 
node 110 (8) since the sum of the weights associated 
with the links in that path is less than the sum of the 

r# weights associated with the links in the via node 115 (C) 
path, i.e., (5) + (1} < (6) + (3). 

Thus, in accordance with known techniques, node 
125, in the "find" phase, constructs a path tree and uses 
that tree to control the rou ting of a message to locate a 

t& node that has the requested multicast information, i.e., 
the televised event 150. An example of such a tree is 
illustrated in FIG. 2, Node 1 20 thus sends a "Find" mes- 
sage to node 1 35 (G) and to node 1.20(D) "in accord with 
the tree. The "Find* message includes, inter alia, fhead- 

2° dress of the message originator, identifier associated 
with the sought-after j'nfdrmation, a request for the iden- 
tity of the node that has the sought-after information. 
The message may also include informal ion characteriz- 
ing the constructed path tree, Accordingly, then, upon 

2$ receipt of the message, node 1 35 returns a Reply mes- 
sage with the cost parameter set to -i. Although node 
120 does not have the sought-after information, it-does 
not discard the message since the path tree indicates 
that the message should be individually routed to nodes 

w iio; 115 and 130, as shown in FIG 2. Similarly when 
the message reaches node 1 10, the node does not dis- 
card the message {even though it does not have the 
©ought-after information), but forwards it to node 105 
(A). Since, it is assumed that node 105 has the sought 

35 after information, then it responds to the received mes- 
sage by returning to node 125 a reply message contain- 
ing the identity (address) of node 105 and with the cost 
parameter set to 0. 

Upon receipt of the latter message, node 125 enters 

jo the "Join" phase, as discussed above, in this phase, 
node 125 constructs the shortest path to node 105 and 
sends a Join message containing the node 125 address 
with a request to join the multicast of the identified event. 
Referring to FIG 2, it is seen that such path would 

^ he via nodes 110 and 120, rather than via nodes 115 
and 120 Node 105 returns a Joih-AGK and then starts 
supplying the televised event to node 125 via the deter- 
mined path. When nodes 110 and 120, which are in the 
path of the multicast, start receiving the multicast infer- 

«o mat ion then they note in their respective internal mem- 
ories that they also have such information. 

Assume at this point that a user associated with 
node 1 30 also wishes to receive the multicast and enters 
a request for that information. Similarly, node 130 eon-- 

§s structs a least-cost path tree and launches its own find 
message in accordance with the tree (not shown). When 
the message reaches node 120, it responds with a reply 
message to node 130 indicating that it has the informa- 



tlon. As discussed above, node \ 30 accumulates the re- 
ply messages and then determines from those message 
which of the nodes having the sought-after information 
is closest to node 130. in the present illustrative exam- 
pi©, the closest node for the desired purpose would be 
node 120. Accordingly, then node 130 may join the mul- 
ticast by sending a Join message to node 1.20, rather 
than to node 1 05 Th us, wh en node 1 20 fee e*ves a pac k- 
©! of such information from node 1.10, it sends a copy to 
node 1 25 and a copy to node 1 30. 

If at this point, the user at workstation 170 enters a 
request to terminate receipt of the multicast, then node 
1 25 forms a ^Leave" message and sends the message 
to node 120 in accordance with the constructed path 
tree rooted at node 125. When node 120 receives the 
message, it stores the message in SocaJ memory and 
terminates the supplying of the multicast information to 
node 1 25 but wiii continue supplying thai information as 
it is received to node 130. If prior to the end of the tele- 
vised event, node 130 launches a "Leave" message., 
then node 1 20. in response to that message and in re- 
sponse to having no other receiver lor the multicast, 
sends a message to node 1 1 0 to terminate the supply ing 
of the multicast to node 1 20. Similarly, node 1 1 0 sends 
a similar message to node 1 05 if it has no other receiver 
for the multicast information, 

A situation could arise in which a node receives, at 
about the same time (concurrently). Find messages 
from a plurality of nodes. -e.g., two nodes To handle this 
situation and preserve the correctness of the distributed 
protocol, a node . e.g., node 125. appends a time stamp 
to a Find message. In this way, if a node, e.g.. node D, 
receives concurrently "Find" message from nodes ^2B 
and 130, then it processes the Find message bearing: 
the earHest time stamp and returns a Reply message to 
the node, e.g., node 1 30, that launched the Find mes- 
sage bearing the latest time stamp. Then, when the least 
cost multicast path is established from node 1 05 to node 
1 20, then node 1 30 launches a Find message after wall- 
ing a random (or a predetermined) period of time and 
then proceeds as discussed above. 

In an illustrative embodiment of the invention, the 
principles of the invention are embodied in a state ma- 
chine which is implemented in each network node for 
each multicast group. An illustrative example of such a 
state machine is illustrated in FIG. 3 and is composed 
of five major states, namely IDLE 301 , WAIT 302, TEN- 
TATIVE 303, ACTIVE 304 and RETRY 305, Before dis- 
cussing FI'GL % It wouid be best to review the different 
message(s) that may be sent by a node attempting to 
join a multicast and the messaged s) that are sent by the 
other nodes in the network in response to a request to 
join a multicast session. Briefly, a node that wants to join 
a multicast tree/session sends a REQUEST message, 
in the manner discussed above. The header of the re- 
quest message contains, inter alia, the identity of the 
multicast information, sender ID, and time-stamp, {it 
may also contain a retry count.) A request message can 



only be originated by a node that is in the I DLE state. A 
node sends a REPLY message in response to receipt 
of a REQUEST message. A REPLY message includes 
the header information of the REQUEST message and 

s an associated cost parameter which identifies the cos! 
of the shortest path from the current node to the nearest 
node that is already on the tree. The coat is updated as 
the REPLY moves f rom one node to another node. The 
cost is set to -1 if there is no ACTIVE node on that par- 

io ticuiar path. A node sends a RETRY message if it de- 
termines that another request is already being proc- 
essed, as discussed above. The request with the earlier 
time-stamp Is allowed to continue while a RETRY mes- 
sage is sent to the originator of the request having the 

75 later time stamp, as mentioned above. A node sends a 
JOIhhREQ message when it wants to Join the multicast 
session/tree. The path to the nearest node is encoded 
within this message. An ACTIVE node sends a JOIN- 
ACK message in response to receiving a JGIN-REQ 
message. The receipt of this message indicates that a 
node is on the multicast tree. A node sends a LEAVE to 
an ACTIVE neighbor node when it wants to leave the 
multicast session/tree. 

Turning then to FIG; 3. Briefly in the IDLE state a 

^ node has no information pertaining to the multicast in- 
formation (or tree). A node enters the WAIT state after 
it has sent/forwarded a REQU E S T message and is wait- 
ing for a response A node enters the TENTATIVE state 
after it has sent/forwarded a JOIN-REQ message fo- 

30 wards the nearest node that is already on the multicast 
tree- In this state; the node is waiting for a JOIN-ACK 
message. A node enters the ACTIVE state when it joins 
a multicast session {i.e., it is on the multicast tree. A 
node reaches this state when It receives a JOIN-ACK 

35 message from a node that is already on the tree. A node 
in the ACTIVE state may also maintain the tree-based 
information regarding all the links that are incident on it 
and belong to the tree. However, the node does not 
maintain any state information about new requests to 

40 pin the tree, A node reaches the RETRY state when it 
is the originator of a REQUEST to join a multicast tree 
and receives a RETRY message via one of the links of 
th e tree . In this state , a node does n ot have to mai nta in 
any state information relating to other requests. Also, 
the node waits for a random period of time before re- 
sending the original REQUEST it may also track the 
number of REQUEST messages that It sends 

An expanded version of the IDLE state is shown in 
FiG. 4. As mentioned above a node initiates a RE- 

so QUEST message when it is in the iDLE state. 

A node in this state only can initiate a REQUEST 
message. A REQUEST message is identified using the 
tuple <senderlD l time-stanip,r0try^-count> ! where send- 
erID is the ID of the node that is the originator of the 

ss message, time-stamp is the value of a counter at the 
senderiD and refry-caunt is the number of attempts the 
node Has made to join ihe ime. The retry-eount is initially 
0. The initial REQUEST message Is forwarded on all the 



Unks via the shortest -path tree rooted at the originating 
node,. The node then enters the WAIT state. The follow- 
ing actbns are taken when the node receives either a 
REQUEST message (action path 401) )or JOIN REQ 
message (action path 402). For example, assume that 
a REQUEST message is received from nods B, and 
therefore contains the tuple <ID B; CNTR 8? RC B >. Then 
the receiving node takes the following actions: 

if the message is not on the shortest path, then send 
a REPLY with cost- -1 towards the originator. Else, 
update the time stamp {focal counter). 

Save the state information of the message. 

Forward the REQUEST message. Change State = 
WAIT. 

if no available link, send REPLY with costal. State 
- IDLE, 

If a JOIN-REQ message is received from node B, 
then the receiving node proceeds as follows: 

Forward JOI N-REQ message to next node. Change 
State = TENTATIVE. 

if current node is the final destination noted in the 
massage, 'then return a RETRY message to the 
originator (Note that this condition may arise if the 
node changes its state from ACTIVE to IDLE during 
the time between the sending of the REQUEST 
message and JOIN-REG message to node B.) 

An expanded version of the WAI T state is shown in 
FIGs. 5A : 5B and 6. For FIGs. 5 A and B , assume that 
a node received a REQUEST message containing the 
tuple <fD Al CMTR A ,RG A > from node A. 

If the node also receives a REQUEST message 
from node 8 : <ID Bt CNTR Bj RC B >. Then the node lakes 
the to flowing actions {path 501 ): 

Update the local time stamp counter 

If the message had not been received via the short- 
est path, then send a REPLY to B, setting cost to -1 . 

If the message is received via the shortest path and 
A precedes Bin time, then send a RETRY message 
to B. 

If the message is feceived via the shortest path and 
S precedes A in time, then send a RETRY message 
to A, Clear state information pertaining to A. Save 
information pertaining to 6 and forward REQUEST 
message. 

If the node receives a REPLY message via one of 



its links, then the node takes the following actions {path 
502): 

Ignore the REPLY message If it does not contain 
s state information .. 

If not the fast reply, then store the cost information 
and wait for other reply messages. 

to If the last REPLY, then determine best message by 
minimizing the {cost field of message 4- link cost}. 
Then forward the best message towards the origi- 
nator of the REQUEST after updating cost, Change 
state = IDLE. 

rs 

If originator of REQUEST message, then compute 
the shortest path to the nearest node. Send JOIN- 
REQ message towards that node via the shortest 
path Change state - TENTATIVE. 

m 

if the node receives a RETRY message Via one of 
its \ in ks / then the node lakes thefol lowing act ions {path 
001 , FIG. 8): 

ss Ignore the RETRY message if it does not contain 
state information. 

Clear the state information and .forward the RETRY 
message towards the originator of REQUEST 

30 

Change state :: IDLE. 

If originator of REQUEST then change state = RE- 
TRY 

35 Increment retry count 

Wait for a random period of time, then resend the 
REQUEST message with the updated retry count 
value, (Note: The same counter value (CNTR) will 
40 5e used to ensure fairness,) 

If the node receives a JOIN-REQ message from a 
node, e.g. : node 6, then the node proceeds as follows 
{path 802, FIG. 8): 

45 

Change state TENTATIVE. 

if next node information is available,, then forward 
the JQIN-REQ message to the next node and send 
$0 a RETRY message to node A. 

If no next node, then send a RETRY message to- 
wards the originator of the JOfN-REQ message. 

An expanded version of the TENTATIVE state of 
FIG a is shown in FIG. 7, in which a node enters the 
TENTATIVE State after it receives a .vJOIN-REQ mes- 
sage originated by anoihef mx^e, e.g., node A. if at that 



time, the node recedes a REQUEST message from 
node B containing the tup?© <iD Q ,CNTR B , &C B >, then 
the receiving node proceeds in the following manner 
(path 701): 

If a REQUEST message is not received via the 
shortest path, then return a REPLY with cost - -1 to 
the originator. Else, 

Update local counter value. 

Send RETRY message towards theo^^ 
message. 

If;. on the other hand, the node receives a RETRY 
Message, then the node takes the following actions 
(path 702): 

if RETRY matches JOiN-REQ, forward RETRY 
message back towards node A. 

Change state - IDLE. 

Ignore it RETRY message does not match JOIN- 
REG. 

If the node otherwise receives a JQiN-ACK Mes- 
sage, then the node lakes the following .actions (path 
703): 

Change State = ACTIVE. 
Forward Join -Ac k to node A. 
Clear all state information. 

Update multicast tree information to include the link 
over which the JOIM-REQ was received: 

An expanded version of the ACTIVE state of FIG. 
3, Is shown In FIG. S, in which a node is already on the 
multicast tree. In that case, the node only responds to 
new requests and join requests. Other messages may 
be ignored. 

if a node In the active state receives a REQUEST 
message from node B containing the tuple <ID Bl GN- 
TRg t RG S >> then the receiving node takes the following 
action (path 801): 

If the REQUEST message is not received via the 
shortest path, then send REPLY message -with cost 
=-i io the originator Else, 

Update [oca! counter Value . 

Send a REPLY with cost = 0. 

If. on the other hand, the node receives a JOIM- 



REQ message from node B t than the node returns a 
JOSN-ACK message to 8 (path 802). if the node other- 
wise receives a LEAVE message from node 8. then the 
node takes the following actions: 

5 

Update multicast tree information, 

If only one ACTIVE neighbor and the node is not 
member of multicast group, then send LEAVE mas- 
to sage to neighbor. 

Change state ~ IDLE. 

An expanded version of the RETRY State is shown 
in FIG. 9. A node enters the RETRY state after sending 
a REQUEST message, Assume that node A is in the 
retry state and the associated tuple information is - 
<ID A ,CNTR A .RG A > : and that node A receives a RE- 
QUEST message from node 8 whose tuple information 
is <iD g! CNTR 8 ,RC B >. For that case., node A 'takes, the 
following actions (path 901): 

If. message is not on the shortest path, send a RE- 
PLY back with cost set to -1 . Update local counter. 

If A precedes B in time, then send a RETRY mes- 
sage towards node B . 

If S precedes A in time, then save B's state infor- 
mation and forward the REQUEST message. Save 
As information and stop A's retry timer (A cannot 
join the multicast group until 8 has joined). 

Change state - WAIT. (A is now waiting for 8) 

lf ? on the other hand, a JOIN-REG message is re- 
ceived from node 8 then the node lakes the following 
actions (path 902); 

- Change state = TENTATIVE. Forward JOIN-REG 
message to next node on the path. 

Save A's information and wait. (A cannot res end 
REQUEST message until S has joined multicast 
group). 

If Retry timer has expired, then increment Retry 
count and send REQUEST message containing the 
following tuple: 

<ID A ,CNTR A> RC A >. The old valm of CNTR A Is 
used to ensure fairness. 

The foregoing may be readily implemented In a net- 
work formed from a plurality of so-called Peer groups, 
in which a peer group is a group of network nodes form- 
ing a smaller network, in particular, a large network 
formed from a -large number of nodes may be logically 
restructured to improve the efficiency of the number. 
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Such restructuring entails forming nodes into groups 
each operating as a smaller network in which connec- 
tion management functions are logically extended to 
each level of the network hierarchy. The state informa- 
tion fe-' maintained at each physical node. In addition, 
each group is represented as a logical node at a higher 
Icvef of the network hierarchy by a peer group leader 
(POL), The PGL maintains separate state information 
for that logical node at that hierarchical love! The logical 
nodes perform the same state transitions as the physical 
nodes at the lowest feve! of the network hierarchy. .In 
that sense., our inventive protocol may be applied to 
such a network With the Mowing modifications (exten- 
sions). 

i) A Joining Node prompts (requests) its PGL to en- 
ter the "Find 5 * phase at the next higher level of the 
hierarchy. At the logical level, pre-established virtu- 
al connections between logical nodes are used to 
send the REQUEST and REPLY messages. During 
the *Find" phase, the logical nodes may make a 
transition from the I OLE state to the WAIT state and 
RETRY state similar to the physical nodes. 

if) It the PGL is already active at the higher level 
(which may mean that some other ACTI VE node ex- 
ists In the peer-group), then this information is re- 
turned to the requesting node. On receipt of the in- 
formation, the requesting node executes the proto- 
col to determine the nearest ACTIVE node within 
ihe peer-group. The ID of the nearest ACTIVE node 
(physical or logical) is returned to the lower level re- 
questing node If the cur rent level is the lowest level, 
then the requesting node enters the "Join" phase. 

iii) Otherwise, the PGL recursively executes the 
above steps at higher levels until it reaches the top 
level of the hierarchy. At that level,, the PGL enters 
the "Find" phase. At the end of the "Find" phase, 
the- requesting node has the 10 of the nearest AC- 
TIVE node. (Note that this IP may either be the 
physical I'D of the node within the same 'peer-group 
(single peer group ease) or the logical I D of a higher 
level node in a logical peer-group (multiple peer 
group ease). 

Based on the available topological information, are- 
questing node determines the path to the nearest node. 
The path may not he complete If the nearest node is a 
logical node in a higher level, bgical peer-group. The 
determined path is stored in the form of a Designated 
Transit List (OIL), as discussed in the Private Network- 
Network interface (PNNI) specification version 1.0*. 
avai labie from the ATM Forum, 2570 West Ei Camino 



Real, Suite $04, Mountain View, California 94040-1313, 
which 'is hereby incorporated by reference. The DTL is 
embedded in the JQIN~REQ message before it is for- 
warded to the nearest node. Oh receiving a JOiN-REQ 
s message, a node executes the following protocol: 

1) if the node is already ACTIVE, it returns a JOIN- 
ACK message. The JO? N- ACK Is returned along 
the same path (hi the reverse direction} to originate 
10 ing node. 

ii) Else, if the DTL stack is not empty, then the 
JOIN-REG message ss forwarded to the next 
node based on the information available in the 
DTL, {Mote that new paths may be added to the 
DTL toy Ingress nodes, as explained In the 
above-mentioned reference. Also note that the 
■JOIN-REG and JOIN -ACK messages may foe 
sent on network signaling channel. When the 

&> JOihhREQ or JOIN- ACK messages are sent 

across border jinks, the logical node at the ap- 
propriate level has to be informed so that the 
logical node can make a state transition to the 
TENTATIVE or ACTIVE state respectively. This 

2£ is done by sending a copy of the JOIN-REQ or 

JOIN-ACK message to the appropriate logical 
node, 

iii) If the DTL stack is empty then the node en- 
ters the "Find" phase to determine the nearest 

so ACT: V E node. The nearest node information is 

then encoded as DTL and the message is far- 
warded to the nearest node. 

Similar actions are taken when a participating node 

35 leaves the multicast group. In this case a LEAVE mes- 
sage is sent to an ACTI VE neighbor node, provided that 
the participant has only one ACTIVE neighbor. The par- 
ticipant node then enters the IDLE state. The neighbor 
node may then forward the LEAVE message to its near- 

40 est neighbor if it is not a participant and has only one 
ACTI VE neighbor When a LEAVE message ts sent 
across a border link, then a copy of the message is sent 
to the appropriate logical node, so that the global state 
of the node can be changed to the IDLE state. 

4S The extended protocol described immediately 
above may be further appreciated when discussed in 
conjunction with the examples illustrated in FIGs. 10 
through 13, in which each FIG. ..illustrates a network 
formed from three peer groups of network nodes (e.g. : 

$o ATM switches) 20 : 1, 202 and 203. The nodes in peer 
group (a) 201 are respectively designated A.I through 
A. 5. (h) 202 are respectively designated B.1 through B 
5 and (e) 203 are respectively designated C.I through 
C.-5. The dark (or tilled in) node serves as the PGL for 

^5 the respective peer group in each of FiGs/1.0 through 
13, Assume for FIG. 10 that node A. 3 wants to join a 
multicast group, and, therefore sends a request to that 
effect to its PGL (node A), which causes that PGL to 



enter the "Find" phase at the- higher leve? as noted by 
the ellipse containing logical PGLs A, 8 and G, Since 
PGL A enters the highest level, it sends a REQUEST 
message to the other members of its pear-group to de- 
termine who has the requested multicast information. 
Assume that PGL A determines that there are no mem- 
bers of the multicast in peer-groups Band C. This infor- 
mation is passed on to node A. 3 and the state of node 
A 3 becomes ACTIVE. The multicast tree now consists 
of a single node A 3. Globally, the state machine for tog- 
ical node A also makes a transition to the ACT! VE state. 
The ACTIVE nodes at each level are shown as boxes 
In FIG. 11. The participant nodes at each level are 
shown as lightly shaded boxes. 

Assume that node C.4 now wants to join the multi- 
cast group, and, therefore sends a request to its PGL 
(node G) to enter the "Find" phase. Node C, in response 
thereto, sends a REQUEST message to logical node B 
and logical node A. (Note that node C may enter the 
RETRY state if there is a concurrent Join request from 
logical node 8.) i? there are no other requests, then only 
logical node A is ACTIVE and this information is sent to 
node C.4 by logical node O. This action completes the 
,! Find ,! phase for node C A 

In the "Join" phase, node C4 encodes a path to 
peer-group A as a DTL and forwards a JOIN -RE Q mes- 
sage to peer-group A. The message enters peer-group 
B, across the border fink (0.2-B.4). Here, node B.4 is 
the ingress node and the DTL stack is not empty (step 
{11} of the "Join" phase). Node B.4 identifies a path 
through its peer-group to peer-group A and appends the 
path to the DTL. It then forwards the message towards 
peer-group A. Node 8 4 also sends a copy of the JOIN - 
REQ message to the PGL node B.I, which maintains 
the global state machine for logical node B. Node B i 
updates the global state machine of node 8 to TENTA- 
TIVE state. Assume that the message enters peer- 
group A across fink (B.5-A.5). The DTL stack is now 
empty (step (iii) of the " Join" phase). Node A 5 upon re- 
ceipt of the message enters the "Find" phase to deter- 
mine the nearest node that should receive the message, 
i.e., node A 3. It then appends the path to node A 3 to 
the DTL and forwards the JOI N-REQto node A 3. Node 
A 3, being in the ACTIVE state, replies io receipt of the 
message by returning a JOIN-ACK message (step (i) of 
the 0 Jo*n K phase). The JOIN-ACK messages retraces 
the path followed by the JOINTED message. When she 
JOfN-ACK crosses the border Brik-(A."5-B.5),. the state 
machine of logical node 8 is updated to the ACTIVE 
state. Logical node C becomes ACTIVE when th a JOIN- 
ACK message is sent across link (B.4-C.2). The resum- 
ing multicast tree is shown as dotted lines in FIG. 1 2. 
Node 8,2 can now join the multicast tree by joining node 
B.4, as shown in FIG, 1 3. 

If participant A 3 leaves the multicast group, then it 
sends a LE AVE message to node A S, which propagates 
the message to node B.5. Node A S also sends a copy 
o? the LEAVE message la node A, 1 , so that the global 



stats machine of logical peer-group A- may be changed 
to the IDLE state. Node 8.5 also sends a LEAVE mes- 
sage to node B.4. However, the propagation of the latter 
message stops at node 8, 4 since that node has two AC- 
5 Ti VE neighbors, nodes B. i and C:Z The resulting tree 
is shown in FIG. 14, Assume now node 8.2 similarly 
leaves the multicast group. In this instant the LEAVE 
message propagates to node C.4. Recall that when the 
LEAVE message is sent across link B.4-C.2, a copy is 
also sent to node 8.1 so that the global state machine 
for the peer-group may be changed to I DLE state. The 
final tree consisting of only node C;4 Is shown in FIG. 1 5. 

t$ Claim* 

1, A method of joining a multicast connection originat- 
ing from a source node distributing multicast infor- 
mation, said multicast connection being established 
£0 in a network composed of a plurality of communica- 
tions nodes, said method comprising the steps of 

at one of said nodes, responsive to receipt of a 
request to receive said multicast information. 

25 construct ing at least one routing tree formed 

from selected paths to each of a number of oth- 
er nodes identified in the tree and sending a 
message identifying said information to the se- 
lected nodes in accordance with the routing 

30 tree, and 

at said one node, responsive to receipt of a 
message identifying said source node as being 
the originator of the identified information, 
as sending a message contain ing a request to join 

multicast distribution of the identified informa- 
tion. 

2- The method of claim 1 f urther comprising the steps 

40 Of 

at the source node, responsive to receipt of a 
message containing a request to join the multicast 
distribution of the identified information, returning 
an acknowledgment message to the originator of 
4$ the message. 

3. The method of claim 1 further comprising the steps 
of 

$Q at the source node, responsive to receipt of a 

message containing a request to join the mul- 
ticast distribution of the identified information, 
constructing a network path tree rooted si the 
source node and extending to the node origi- 
ns nating the message, and 

supplying the multicast information via the path 
tree rooted at the source node. 



& The method of claim 3 wherein said multicast tree 
includes at one intermediate node between the 
so^ res node and the node originating the message 
and wherein said method further comprises the 
steps of 5 



S. A method of joining; a mult icast connection originat- 
ing from a sou nee node distributing multicast infor- 
mation, saklmultieast connection being established 
in a network composed of a plurality of communica- 
tions nodes, said method comprising the steps of 



at the intermediate node, responsive to receiv- 
ing from another one said nodes a message 
containing a request for said mult least informa- 
tion, returning to said other one of said nodes 10 
a reply message indicating thai said intermedi- 
ate node can supply said mu tost information, 
and 

at said other one of said nodes accumulating *5 
all reply messages to its request for the multi- 
cast information and determining which of 
nodes returning a reply message is closest to 
said other one of said nodes, and 

20 

sending a message to join the multicast to the 
determined Closest one of the nodes that re- 
iumeda reply message to said other one of said 
nodes, 

2$ 

Sv Th e m ethod of claim 4 f u rth er comprising th e step of 
at the doses! one of the nodes, responsive to 
receipt of the join message and thereafter respon- 
sive to receipt of multicast information via the path 
tree rooted at the source node, sending a copy of so 
the received multicast information to the other one 
of said nodes, 

& The method of claim 5 wherein said intermediate 
node is said closest one of the nodes and wherein 
said method further comprises the steps of 

at said Intermediate node, responsive to re- 
ceiving from said one node a message addressed 
to said source node and requesting a termination of 
the sending of the rftultic&st information to said one 
nods, terminating the sending of the multicast infor- 
mation to said one node and continuing to supply 
the multicast information as it is received to said oth- 
er one of sa*d nodes. 

4$ 

7, The method of claim 5 wherein said intermediate 
node is said closest one of the nodes and wherein 
said method further comprises the steps of 

at the intermediate node, responsive to re- 
ceiving from said other one of said nodes a mes- so 
sage addressed to said source node and request ing 
a termination of the sending of the multicast infor- 
mation to said other one of said nodes, terminating 
the sending of the multicast information to said oth- 
er one of said nodes, and responsive to having no 
other recipient for said multicast information ■, send- 
ing the received termination message to the source 
node. 



at a network node, responsive to receiving from 
first and second other ones of the network 
nodes respective message requests to join the 
multicast, determining as a function of a prede- 
termined parameter which one of the first and 
second nodes is to he connected first to the 
multicast connection and sending a wait mes- 
sage to the other one of the first and second 
nodes, 

forwarding the message received from said one 
of said first and second nodes over a path con- 
tained in that message, and 

thereafter responsive to receipt of multicast in- 
formation f rom a source via a path rooted at the 
source, supplying the multicast information Jo 
said one of said first and second nodes 

9, The method of claim 8 further comprising the steps 
of 

at said other one of said first and second nodes, 
response to receipt of the wait message, wait- 
ing a predetermined period of time, and 

at the expiration of that period of time, again 
sending a message requesting receipt of the 
multicast information. 

10. The method of claim 9 further comprising the step of 

at said network node, responsive to receipt of 
the request message from said other one of said 
first and second nodes, supplying. said multicast in- 
formation to said other one of said first and second 
nodes as it is received from the source. 

11. The method of claim 9 further comprising the steps 
of 

at said network node, responsive to receiving 
from said one node of said first and second modes 
a message addressed to said source node and re- 
questing a termination of the sending of the multi- 
cast information to said one of said first and second 
nodes, terminating the sending of the multicast in- 
formation to that node and continuing to supply the 
multicast information as it is received to said other 
one of said first and second nodes. 

1 2, The method of claim 9 further comprising the steps 
of 

at said network node, responsive to receiving 



from sa$d other one of said first and second nodes 
a message addressed to sad source node and re- 
questing a termination of the sending; of the multi- 
cast information to said other one of said first and 
second nodes, terrninating the sending of the mul - 
ticast information to said that node ; and responsive 
to having no other recipient for said multicast infor- 
mation, sending the received message requesting 
termination io the source node. 
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